This section is intended to introduce the reader to various aspects of the art that may be related to various aspects of the present invention. The following discussion is intended to provide information to facilitate a better understanding of the present invention. Accordingly, it should be understood that statements in the following discussion are to be read in this light, and not as admissions of prior art.
The present invention generally relates to telecommunication services which execution depends on time and date. More particularly, the invention relates to those services which execution involves more than one entity, wherein each entity is located in a different time zone.
Conventional telecommunication networks are generally provided with a subscriber database storing all relevant subscriber data, including service data per subscriber, for all the subscribers of a particular network operator. In conventional mobile networks, any subscriber may at a certain time be roaming far away from the subscriber database holding the subscriber data for said subscriber.
Nowadays, there are services that can be invoked by the subscribers, or triggered by a network entity, and wherein this invocation or trigger may depend on date or time of the day, namely, time-dependent services. Regarding the execution of these time-dependent services, especially where the subscriber is roaming in an area located in a different time zone than the time zone where the subscriber database or other network entities are located, the service may be executed at an unexpected time. In this field of application, US 2006/0252438 teaches a method for determining the time zone where the user's equipment is located in order to apply this time zone for execution of time dependent services for this subscriber. This teaching may be appropriate for services such as, for example, conditional call forwarding services depending on time of the day; however, other services such as IMSI Changeover, for example, may better depend on the time zone of the operator's infrastructure.
Moreover, current trends in dedicated database systems point out for a separation of application logic and subscriber data in different physical network elements: Front Ends in charge of the application logic and Directory DB storing the subscriber data. This approach is currently known as Data Layered Architecture (DLA). DLA basically consists of a number of Front-Ends (FE) servers implementing the logic of the application or service, and a Common Directory (CD) database serving as central storage point for subscriber data of HSS, HLR, AUC, MNP, Application Servers, etc.
Where a DLA is utilized as subscriber database, the execution of time dependent services may vary from one network to another depending on different operator's preferences. Since on serving a particular subscriber the DLA includes an FE server and a CD database, on executing a time dependent service for said subscriber there is a need to determine which is the time zone to apply.
Moreover, different operators operating DLA may have different criteria in respect of what time zone should be applied for different time dependent services.
The present invention is aimed, at least, to minimize the above drawbacks and provides a technique to decide on subscriber basis the time zone to be applied for any time dependent service this subscriber can have.
Due to the own nature of Layered Architecture, its components, e.g. HSS-S, AS, etc., are spread across the operator network in several geographical sites. In case of large countries, it may happen that not all components are placed in the same Time Zone. Also, independently of that fact, a subscriber may physically be in a different Time Zone than the server which is giving service to him.
When one traffic or provisioning event occurs, the FE Server (AS, or simply the Server) downloads the service data and checks the date and time stored in the CD database with the date and time of local Server, if they match or the Server one is more recent, then it is executed.
So when the time zone of the time dependant service stored in the Directory DB and the time zone of the Server executing the logic coincide with the time zone where the Subscriber is located, the task is executed exactly at the date and time desired and specified. (Along the document the term subscriber is used. It means the entity using the telephone equipment and the services. Other terms can be user, subscriptions etc.)
The problem occurs when the time zone where the Subscriber is located, the time zone of the Server executing the service, or the time zone of the stored service date and time do not match.
When it happens, what time zone shall be used? The time zone stored for the Service or the Subscriber's time zone or the Server's time zone?
The consequences of wrong time calculation can be uncomfortable for the Subscriber experience. For example a Subscriber has configured a Call Forwarding Unconditional Service with a time range everyday so that all calls received in that period of time are diverted to a voice mailbox, e.g. from 19:00 to 07:00 all received calls are forwarded to the voice mailbox. While the time zones of: the service, the Server, and Subscriber location match the service works fine.
Just when the Server or Subscriber location time zone differs from the configured time zone of the Service, it works weirdly. Let's imagine that the Subscriber moves to a visited network some time zones away from his/her original one, for example the period of time in the new time zone correspond to 14:00 to 02:00. It means that the Subscriber stops receiving call at 2 pm, so important calls can be diverted to voice mailbox. But also the Subscriber begins receiving calls at 2 am, when s/he is still sleeping. So the experience is a bit annoying.
This problem can arise in any type of systems but in distributed systems, where the Server and the Directory DB are different physical components in different geographical locations covering different time zones, it is more evident and even more frequent.